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PREFACE 


This technical report was prepared by the staff of the Research Institute, The University 
of Alabama in Huntsville. The purpose of this report is to provide documentation of the work 
performed and results obtained under delivery order 51 of Marshall Space Flight Center 
(MSFC) Contract No. NAS8- 38609. Mr. Gary A. Maddux was Principal Investigator for this 
three year level of effort. Mr. David Jex of the Microgravity Experiment Projects Office 
provided technical coordination. 

The views, opinions, and/or findings contained in this report are those of the author(s) 
and should not be construed as an official NASA position, policy, or decision unless so 
designated by other official documentation. 

I have reviewed this report, dated ft ^ and the report contains no classified 

information. 
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1.0 INTRODUCTION 


The System Management and Production Laboratory, Research Institute, The 
University of Alabama in Huntsville (UAH), was tasked by the Microgravity Experiment 
Projects (MEP) Office of the Payload Projects Office (PPO) at Marshall Space Flight Center 
(MSFC) to conduct research in the current methods of written documentation control and 
retrieval. The goals of this research were to determine the logical interrelationships within 
selected NASA documentation, and to expand on a previously developed prototype system to 
deliver a distributable, electronic knowledge-based system. This computer application would 
then be used to provide a "paperless" interface between the appropriate parties for the required 
NASA documentation. 


2.0 BACKGROUND AND OBJECTIVES 

The Microgravity Projects Office (MPO) of the Space Systems Office at MSFC is 
currently responsible for collecting and coordinating experiment/facility specifications and 
requirements between NASA personnel and various colleges, universities, research centers, and 
other public- and private-sector organizations that are selected or are requesting to fly their 
respective experiments on space flights. This coordination involves the communication of 
flight hardware requirements and the preparation and review of all documentation transpiring 
between NASA and the research groups. To assist and accommodate these customers of 
NASA, an effort was undertaken to research, analyze, and evaluate the current procedures 
involved in the information gathering activities associated with experiment development. 

The MPO identified a need to develop a software package that will lead experiment 
developers through the development planning process, obtain necessary information, establish 
an electronic data exchange avenue and allow easy manipulation/reformation of the collected 
information. A MS-DOS compatible software package called the Automated Payload 
Experiment Tool (APET) has been developed and delivered. The APET system was designed 
to assist in the preparation of several NASA documentation packages including: Science 
Requirements Document (SRD), Experiment Requirements Document (ERD), Science 
Requirements Envelope Document, PPO Payload Safety Implementation Approach, and 
MS AD Project Plan. Several of these APET software modules were field tested with different 
teams from the research groups and their suggestions/comments were documented. 

The objective of this task was to expand on the results of APET work previously 
performed by UAH and provide a modified version of the Project Plan to include the 
requirements of the MSFC Project Plan. The software will assist the scientist or engineer in 
generating the appropriate documentation on a computer platform in which they are familiar. 
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3.0 CURRENT ENVIRONMENT 


The current environment of manual data gathering and information dissemination is 
excessively reliant on paper as the primary medium of transfer. This reliance on a static media 
adds exponentially to the complexity of a process that by its nature is elaborate. Changes to a 
document stored on an information media that requires physical manipulations are costly and 
burdensome. With no method in place to ensure that changes are incorporated throughout 
follow-on documents, (other than manual verification), modifications to science, experiment, 
safety, and other documents are more susceptible to human error than necessary. 

The design, development and preparation of an experiment to fly in space are time 
consuming tasks demanding a great deal of technical and disciplinary knowledge. Reducing 
the time required to prepare an experiment and its supporting documentation is of vital interest 
to the Microgravity Science Applications Division (MSAD). Methods of developing and 
utilizing state of the art information technologies are of prime concern in simplifying the 
critical Principal Investigator (PI)/Payload Element Developer (PED) interface. 

4.0 ACTIVITIES 

The validation of the APET system began after the completion of two software 
modules, the Science Requirements Document (SRD) and the Experiments Requirements 
Document (ERD). The validation process required members of the software development team 
at UAH to demonstrate the software to proposed Principal Investigators (Pis), assist the Pis in 
using the software to create the documents and then interviewing the Pis about the quality and 
ease of use of the software. 

4.1 Validation of the APET Software 

The first phase of this contract was from September 92 through September 93. During 
this phase several demonstrations and interviews were conducted. A software team of three 
members provided several presentations of the APET system at different locations. The 
demonstrations were conducted at Lewis Research Center, Cleveland, OH; Marshall Space 
Flight Center, Huntsville, AL; and NASA Headquarters in Washington DC. 

Several SRD software packages and a few ERD software packages were distributed 
during these presentations. A number of positive comments were received at the presentations, 
but there has been little feedback since these initial efforts. Follow-up attempts were made to 
contact these Pis, but because of flight delays, funding fluctuations, etc., few suggestions have 
been forthcoming. None of the members have requested help with the software. From the 
comments provided on the SRD software, several issues were addressed. Some dealt with the 
MSAD outline and some were user guide and software issues. All issues were addressed and in 
some cases used to improve the APET system. 
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At the end of the initial contract period of performance no additional suggestions or 
comments were returned to the UAH software team. None of the Pis were at the stage of 
experiment development where an ERD was required so no information about the ERD 
software had been received. Due to the lack of response, contracted funds were still available 
so a request to extend (at no additional cost) the contract until March 10, 1994 was made. This 
began the second phase of the contract. 

During the second phase, requests were made for the development of the Science 
Requirements Envelope Document, the MS AD Project Plan and the Safety Data software 
packages. These packages are mainly used by Program and Project Managers. The 
demonstration of these packages opened up a new level of users. Several presentations were 
conducted at MSFC to demonstrate the use of these packages and to distribute copies. Possible 
users were contacted but most of them were more familiar with the Macintosh platform and did 
not show an interest in learning to use the APET system. 

In January of 1994 a second request for a no cost contract extension was made for 
September of 1994. This is considered phase three. In February a third request was made for 
an extension through July 30, 1995, with additional funds for further software development. 
Under this fourth phase the request was made for the Project Plan software to be updated to 
include the MSFC MMI 7120.1 version of a Project Plan. During the development of the 
updated version it was requested that the NHB 7120.5 version of a Project Plan also be 
included. The finished updated version includes the MS AD 100-0 version, the MMI 7120.1 
version and the NHB 7120.5 version. It was completed and ready for distribution in mid July 
1995. 

4.2 Upd a te of APE T P roj ect Pl a n Softw.ats 

A Project Plan is the basic planning document that describes the overall plan for 
proceeding with a project. Project Plans are unique to each project and the format and level of 
detail vary with the size, complexity, sensitivity and other characteristics of the project. The 
Project Plan covers the project to completion, including operational and data analysis periods. 

The original version of the APET Project Plan completed answers for just the MS AD 
1 10-0 version that is required by MS AD, however, several Project and Program Managers were 
asked to complete one of the other two versions as well. Therefore, a request that the software 
include the capability to complete the other versions would be of great help. A description of 
the different versions is included in the following sections. All the versions are similar in 
development because they require narrative answers to a specific list of questions. However, 
each version of the Project Plan has a different outline and requires different levels of 
information about the project. For example, the answer for Safety in the NHB 7120.5 version is 
broken down into subheadings, in the MSAD version it is a single answer, and in the MMI 
7120.1 version it is grouped together with Reliability and Quality Assurance. 
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In response to the difference in answers, the software will maintain separate files for 
each answer, but will allow the user to incorporate answers from one version into another for 
editing. This allows the user to modify the text as needed for each version, however, the user 
will not have to start from scratch when completing a different version. Each version uses an 
outline format that allows the user to select a main heading (Safety), and then if applicable a 
subheading (Industrial Safety), to complete the answers. The outline approach provides the 
user with control over which sections they select to complete. When the user feels the 
document is complete, there is an option that allows the user to inquire whether all the sections 
have been completed and then view or print the document. 

4.2.1 MS AD 100-0 Project Plan 

The Microgravity Science and Applications Division (MSAD) requires that a MSAD 
Project Plan be submitted and approved prior to making a major commitment of resources to an 
MSAD project. MSAD Project Plans are to be prepared in final draft form for the 
Requirements Definition Review (RDR). 

Plans are prepared and submitted for all flight experiments. Project Plans are reissued, 
modified, or amended for reflights depending on the complexity of the task. A plan's 
preparation is the responsibility of the designated Project Manager at the responsible NASA 
center. The Project Manager will sign the MSAD Project Plan as the preparer; the Project 
Scientist and the Principal Investigator will sign as concurring. The MSAD Project Plan will 
be signed off at the NASA center prior to submission to Headquarters by the appropriate 
center's authorities. When the Program Scientist and Program Manager sign to register their 
concurrence, the MSAD Project Plan will be submitted to the MSAD Director for approval. 

The Project Manager is responsible for updating the MSAD Project Plan when 
significant changes occur (such as changes in scope, organization, or roles and responsibilities). 
This does not apply to resources, schedules or manpower, which are updated through normal 
budgeting and project monitoring activities. The Project Manager will establish a change 
control process for maintaining the MSAD Project Plan and other project documentation. 

4.2.2 MMI 7120.1 Project Plan 

This document contains the guidelines for preparation of MSFC Space Flight Project 
Plans. This instruction applies to all organizational elements of MSFC involved in the 
planning, definition, and preliminary design of space flight programs/projects. 

Major MSFC research and development projects will be undertaken only on the basis 
of plans and analyses that clearly define the need and work to be done; set forth progammatic, 
managerial, resources and schedule implications; and provide assurance that the required 
technology can be made available. Project Plans will be the systematic approach to the 
planning, review, approval and conduct of MSFC research and development projects. 
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4.2.3 NHB 7120.5 Project Plan 


This document is prepared by the field installation that establishes the overall plan for 
implementation of the project. The Project Plan emphasizes the management and 
programmatic aspects of the project rather than technical information, and establishes the 
agreement(s) between the Program Associate Administrator (PAA) and the involved FID(s) 
(Single Field Installation Programs), or between the Program Manager at the Host Field 
Installation (HFI) and the field installation project managers (Multiple Field Installation 
Programs). 

4.3 Listing of Other APET Software 

Over the course of this contract several software packages have been developed for the 
use of Pis and PEDs. A review of each of the packages is provided here to give a reference to 
the total effort provided under this contract. 

4.3.1 Science Requirements Document 

According to the MSAD Management Plan, "The Science Requirements Document 
(SRD) is the basic document which levies the science requirements on the hardware. As such, 
the document must first provide adequate justification for conducting the experiment in space 
and then delineate and justify the individual science requirements. The science requirements 
include the observational and environmental data requirements necessary to meet the science 
objectives." 

The SRD is the first documentation requirement to be met by the Principal Investigator. 
It was also the logical beginning for the APET software. The previous version of the SRD 
contained 52 questions, however, the MSAD has since reviewed the questions and now the 
SRD section of APET consists of a query of 35 questions concerning the description of the 
experiment, the limitations of non-space testing, and the potential benefits from the space 
environment. 

The answers to the 35 questions are narrative in form (other parts of APET have fill-in- 
the-blank or answers chosen from a list). The user has the option of answering these questions 
sequentially or randomly. An option also exists to answer only the unaddressed questions, so 
that at any time, the user can see how many questions remain. There are a number of options 
available to the user to make the documentation process more efficient. An example of a more 
efficient option is during the question/answer session, when the user has the option of 
viewing/editing related answers on selected questions. This adds to the consistency of the 
material, and provides an easier data retrieval method for the user. 
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4.3.2 Experiment Requirements Document 

The Experiment Requirements Document (ERD) is used by the payload element 
developer and/or the principal investigator to define experiment requirements to be 
accommodated by the Space Transportation System (STS) for a given mission. The ERD is the 
logical follow-on document to the SRD. While the SRD justifies the need for a space 
environment and generally describes experiment requirements, the ERD expands on these 
generalities and requires specific experiment specifications. 

Because of the more exacting nature of the ERD, the user faces more demands to 
respond to questions with exact numbers rather than narrative descriptions. Therefore, the ERD 
user prompts will often ask for a number or word to be selected from a limited list of 
appropriate answers, or supply a short (one or two word) answer to the software query. 
Because of the more demanding requirements of the ERD, the software has a much deeper level 
of complexity. Questions with a limited number of answers or questions that require logical 
responses (YES/NO) can be checked against previous answers to ensure that conflicting or 
mutually exclusive responses are not accepted. This built-in “expertise” adds much to the 
integrity of the user supplied data, and thus makes the information contained in the ERD more 
consistent and useful. 

The ERD section of APET is a great deal larger than the SRD. There are twelve 
sections of the ERD, several of which taken separately would be as large as the SRD in its 
entirety. However, based on the requirements of the experiment, complete sections of the ERD 
can be eliminated. The ERD is also more technically complex than the SRD, containing far 
more terminology, acronyms, etc., than the other APET modules. Therefore, the uses of 
hypertext definitions, examples, graphics and hypertext reference sections are more widely used 
in the ERD. 

The most critical of the ERD sections is the first, which deals with the experiment’s 
functional objectives. Each experiment contains one or more functional objectives, which in 
turn are composed of one or more steps. Follow-on sections in the ERD refer back to and are 
based on the answers given in ERD Section One. The APET software helps the user by 
requiring that Section One be completed before these follow-on sections, and also aids by 
ensuring that if a functional objective is deleted, that the follow-on sections that refer to that 
deleted functional objective will also be deleted. Again this adds to the consistency of the 
material, and provides an easier documentation method for the user. 

Because of the additional size and operability of the ERD the system requirements for 
this software package are somewhat larger than the other packages within the APET system. 
The ERD requires the use of at least a 486 PC with 14M (megabytes) of space on the hard drive 
for the software and another 1M for the data files that will be created. Of course the amount of 
space needed for the data files depends on the size and complexity of the project being defined. 
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4.3.3 Science Requirements Envelope Document 

The Science Requirements Envelope Document provides an envelope or volume of 
science requirements for a type of experimentation that is intended to encompass the science 
requirements generated by individual experiments of that type. The primary purpose of the 
document is to provide science requirements against which hardware can be conceptualized 
such that later, when specific Pis are chosen, their individual requirements will fall within the 
requirements originally stated in the Science Requirements Envelope Document. 

The Science Requirements Envelope Document is very similar to the SRD. The 
primary difference is not the questions, but in the user responses, where a range of values are 
given for a capacity rather than a discreet measurement for an experiment. To complete the 
Science Requirements Envelope Document, questions were taken directly from the MSAD 
Management Plan. 

4.3.4 PPO Payload Safety Implementation Approach 

The PPO Payload Safety Implementation Approach designates the safety-related 
activities and documentation required of individual Payload Element Developers (PED). This 
document is applicable to all MSFC Payload Project Office managed Space Transportation 
Systems (STS) attached payload missions and to all of the PEDs for those missions. STS 
attached payloads include Spacelab dedicated missions, middeck payloads, and partial-payload 
missions. A partial-payload mission is a flight that is not a Spacelab dedicated (unique) 
mission and is shared with other payloads. Such missions are also referred to as mixed cargo 
missions. Partial payloads are defined as those payloads that do not require a Spacelab module 
or the Spacelab igloo. 

The PPO Payload Safety Implementation Approach requirements include the 
information required in the safety certification of instruments, facilities, Mission-Peculiar 
Equipment (MPE), and Instrument Ground Support Equipment (IGSE) that constitute a STS 
payload or payload complement for which the PPO has management and integration 
responsibility. This information is documented in a PED Safety Compliance Data Package and 
is reviewed by the Payload Mission Manager (PMM) to ensure overall payload safety. Data 
packages are completed for both flight hardware and ground hardware. These data packages 
are provided at a series of progressive reviews that require current updated and scaled data to 
reflect the maturity of the hardware. 

Each data package has different requirements but the user’s response is either to 
complete a narrative answer, fill in the blank or select the answer from a list. The size of the 
document depends on the type of experiment and the amount of detail required to fully describe 
the functionality and emergency procedures. The APET software provides for the variation in 
content. 
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5.0 APET SOFTWARE COMMENTS 


The most valuable comments made about the APET software are not the compliments, 
but the criticisms. Without the customer’s inputs of what is still required in the system, it 
would be difficult to determine the improvements necessary to make it a valuable tool for the PI 
and/or PED. We have looked forward to comments or suggestions that the Pis and/or PEDs 
would provide about all the APET software packages, but not many were received. From those 
that were received many have been incorporated into the specific software packages and the 
overall system. One of the main improvements brought about by the use of the SRD was the 
reduction in the number of questions. This was caused by the use of redundant answers to 
many of the questions, which became more evident after using the software. 

6.0 CONCLUSIONS AND RECOMMENDATIONS 

Considering the preliminary comments of the users who have taken part in the 
distribution of the APET software, APET fills a need to automate the documentation process. 
However, more work needs to be done to enhance the APET system and improve user 
acceptance. 

It is recommended that the findings of this research be used to examine the 
documentation requirements placed on the PI. There are instructions in the NASA-supplied 
hardcopy documentation that offer little information as to the amount of detail required to 
adequately answer the questions. These questions cause problems for the PI, and add unneeded 
complexity to the overall task. It has been suggested that the software be modified to include 
examples of what is expected from the user, specially in terms of the Project Plan’s graphic 
examples. Example answers could further be developed to provide the users a model that could 
be used as a base answer, then customized for individual responses. 

It is realized that many people are reluctant to learn a new software package if it is not 
mandatory or if they feel it is not worth the effort. The PPO and UAH have tried to make using 
the APET software as easy as possible by providing free instruction and assistance to anyone 
who requires it. However, there has been little response from the Pis who have received copies 
and even less response from project managers/scientists who might use the software themselves 
or advise Pis about its availability. The main emphasis of the APET software is the reusability 
of supplied answers and the cross reference of the information. If users have the understanding 
that the SRD is a one time only document and the only one they must prepare, they tend to be 
even more reluctant to spend the time learning the software. It is recommended that a stronger 
emphasis be used by the project managers/scientists to support the use of the APET in 
gathering information about projects. The information gathered can be reused in other support 
documentation, such as the Project Plan or the PPO Payload Safety Implementation Approach. 
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